On 9 July 2020, I received a new Dell XPS 8930. From about 13 August 2020, I have had a series of BugCheck events (Event ID 1001), logged in the System log. All of them, except two, were code 154. Could I find the cause? I thought I had but it was a false dawn.
Date of unexpected shutdown | Reported by eventlog | BugCheck date | Code (parameter 1) |
---|---|---|---|
Th 13 Aug 03:02:36 | 13 Aug 07:44:16 | 13 Aug 07:44:17 | 154 |
Sa 15 Aug 15:09:08 | 16 Aug 08:52:09 | 16 Aug 08:52:12 | 1a (6001) |
Sa 22 Aug 16:29:04 | 23 Aug 09:27:59 | 23 Aug 09:28:02 | 154 |
Th 27 Aug 13:12:41 | 27 Aug 13:38:13 | 27 Aug 13:38:16 | 154 |
Mo 31 Aug 14:12:32 | 31 Aug 15:46:37 | 31 Aug 15:46:40 | 154 |
We 16 Sep 15:21:16 | 16 Sep 16:00:26 | 16 Sep 16:00:29 | 3b (c0000006) |
Su 20 Sep 11:04:50 | 20 Sep 16:11:45 | 20 Sep 16:11:48 | 154 |
Fr 25 Sep 19:23:05 | 26 Sep 11:26:32 | 26 Sep 11:26:36 | 154 |
Mo 19 Oct 19:10:48 | 20 Oct 08:56:37 | 20 Oct 08:56:40 | 154 |
Sa 24 Oct 17:31:49 | 25 Oct 09:04:17 | 25 Oct 09:04:21 | 154 |
Unexpected system shutdown
Before each BugCheck event, a EventLog Event ID 6008 was logged, reporting that the previous system shutdown at a specified date and time was unexpected. These are shown in the table above.
Update history
The last peripheral that I had added to the PC had been added on 15 July, a WD 1 TB Elements portable external hard drive (USB 3.0). It seemed unlikely that a peripheral was the cause of the problem.
There was a feature update to Windows 10, version 2004 on 19 July. The Event Viewer logs start from that date. On or before 13 August, the following had been installed by Windows:
- 19 Jul (quality) Security update Adobe Flash Player (KB4561600)
- 19 Jul (quality) Cumulative update .NET Framework (KB4565627)
- 24 Jul (driver) Rivet Networks LLC – Extension – 2.2.3267.0
- 26 Jul (driver) Qualcomm – Bluetooth – 10.0.0.953
- 3 Aug (driver) Rivet Networks – Net – 9.0.0.50
- 7 Aug (driver) Qualcomm Atheros Communications Inc. – Net – 12.0.0.948
- 12 Aug (quality) Cumulative update Windows 10 version 2004 (KB4569745)
- 13 Aug (quality) Cumulative update Windows 10 version 2004 (KB4566782) Installation appears to have started at 02:26:55.
and the following had been installed by either Dell SupportAssist or Dell Update
- 29 Jul 20:11:21 Dell XPS 8930 System BIOS – 1.1.15 (urgent)
- 12 Aug 17:09:01 Dell Update Application for Windows 10 – A00 (recommended)
- 12 Aug 17:09:01 Intel Management Engine Interface Driver – A07 (urgent)
I had also kept the NVIDIA GeForce Game Ready Driver up to date, but did not have the history of that. The current driver was version 456.38, released on 17 September 2020.
Given the timing, could the Intel Management Engine Interface Driver update be the cause? Dell provided me with a link to re-install the intel-management-engine-interface-driver_cgy46_win_2014.14.0.1540_a07.exe
, which I did at about 13:07 on 28 September. After that, 24 days had passed without an event. Then, on 20 October 2020, the events began to occur again.
Bug Check codes
Code 154 is UNEXPECTED_STORE_EXCEPTION
, indicating that the kernel memory store component had caught an unexpected exception.
Code 1a is MEMORY_MANAGEMENT
, indicating that a severe memory management error had occurred. A parameter 1 of 6001, indicates that the memory store component’s private memory range was corrupted, causing it to become inaccessible.
Code 3b is SYSTEM_SERVICE_EXCEPTION
, indicating that an exception happened while executing a routine that transitions from non-privileged code to privileged code. A parameter 1 of c0000006 is a STATUS_IN_PAGE_ERROR
.
Diagnostics
I followed Microsoft’s advice for Code 154, and ran DISM
(Deployment Image Servicing and Management), SFC
(System File Checker) and Windows Memory Diagnostic
. All reported nothing was amiss. I also looked in Device Manager, but no devices indicated any problems.
I followed Dell’s initial advice, and ran thorough Diagnostics from the BIOS (F12 key on power on). After almost 4 hours, the diagnostic reported that all tests had passed, with Validation: 1171154
.
However, after the 19 October event, SFC
reported a problem:
1 2 3 4 |
Windows Resource Protection found corrupt files and successfully repaired them. For online repairs, details are included in the CBS log file located at windir\Logs\CBS\CBS.log. For example C:\Windows\Logs\CBS\CBS.log. For offline repairs, details are included in the log file provided by the /OFFLOGFILE flag. |
I provided Dell with further information, including Event Viewer logs. Dell concluded that the motherboard and SSD should be replaced.
After the 24 October event, however, SFC
reported that it did not find any integrity violations. Perhaps the corrupt files were a result of the 19 October event, not a cause of it.
The events of 13 August
At 02:56:36, the system entered sleep because it was idle. At 02:56:37 it resumed from sleep. It had returned from a low power state by 02:58:10. The wake source was: Windows will execute 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Reboot_AC' scheduled task that requested waking the computer.
That was the last event until 07:43:40, when Kernal-General reported that the operating system had started.
The events of 15 August
Between 14:16:38 and 15:03:29, the start type of the Background Intelligent Transfer Service (BITS) service was changed to and from demand start to auto start, six times. The last entry was to change from auto to demand. That was the last event until 16 August, 08:51:59, when Kernel-General reported that the operating system had started.
The events of 22 August
At 16:14:08, Power-Troubleshooter reported that the system had returned from a low power state. The wake source was: Device -Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
. That was followed by two reports that a service was installed in the system: 16:28:04 PCDSRVC{628864C0-331E8A33-06030000}_0 - PCDR Kernel Mode Service Helper Driver
and 16:28:05 Nal Service
. That was the last event.
The events of 27 August
At 10:03:33, the McAfee Service Controller reported that msk80service MMS Service had entered the running state. Next, at 12:00:00, EventLog reported that the system uptime was 354732 seconds. That was the last event until 13:18:02, when Kernel-General reported that the operating system had started.
The events of 31 August
At 13:26:06, Power-Troubleshooter reported that the system had returned from a low power state. The wake source was: Device -Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
. Between 13:41:02 and 14:21:31 (somehow, after the time the system is reported as having shut down), the start type of the BITS service was changed to and from demand start to auto start, ten times. The last entry was to change from auto to demand. That was the last event until 15:46:27, when Kernel-General reported that the operating system had started.
The events of 16 September
Between 11:20:32 and 15:40:03 (somehow, after the time the system is reported as having shut down), the start type of the BITS service was changed to and from demand start to auto start. The last entry was to change from demand to auto. That was the last event until 16:00:16, when Kernel-General reported that the operating system had started.
During the period, a few times (the last at 15:21:37), Distributed COM reported that the machine-default permission settings did not grant Local Activation permission for the COM Server application with CLSID {C2F03A33-21F5-47FA-B4BB-156362A2F239} and APPID {316CDED5-E4AE-4B15-9113-7055D84DCC97}
to the user HATTIFATTENER\mike SID (S-1-5-21-327590312-1299308036-2643155808-1001) from address LocalHost (Using LRPC) running in the application container Microsoft.Windows.ShellExperienceHost_10.0.19041.423_neutral_neutral_cw5n1h2txyewy SID (S-1-15-2-155514346-2573954481-755741238-1654018636-1233331829-3075935687-2861478708).
The events of 20 September
At 10:38:54, Power-Troubleshooter reported that the system had returned from a low power state. The wake source was: Device -Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
. That was the last event until 16:11:35, when Kernel-General reported that the operating system had started.
The events of 25 September
There were very few events after 13:12:14. At 17:55:31, DistributedCOM reported that the application-specific permission settings did not grant Local Activation permission for the COM Server application with CLSID
{37399C92-DC3F-4B55-AE5B-811EE82398AD} and APPID {37399C92-DC3F-4B55-AE5B-811EE82398AD}. At 18:11:59, it reported that those settings did not grant Local Activation permission for the COM Server application with CLSID {C2F03A33-21F5-47FA-B4BB-156362A2F239} and APPID {316CDED5-E4AE-4B15-9113-7055D84DCC97}. That was followed by two reports that a service was installed in the system (both after the time that the system had shut down): 19:24:56 PCDSRVC{B834E4C0-7CAAC9AD-06030000}_0 - PCDR Kernel Mode Service Helper Driver
and 19:24:57 Nal Service
. That was the last event until 11:26:23, when Kernel-General reported that the operating system had started.
Common factors
It is difficult to spot any common factors in the events. One thing that may be common is that the system had come out of sleep or was idle. However, the PC is always on, and so it often comes out of sleep or is idle without these events.